In any browser-based architecture, no matter what presentation techniques and architecture designs are employed at the back-end server side, it must finally return to a browser markup language that can be recognized by the browser, such as HTML (Hyper Text Markup Language), XML (eXtensible Markup Language), WML (Wireless Markup Language), etc.
When generating a dynamic web page, usually web page designers (e.g., art designers) will first design a template, and then the template is populated by developers to realize various dynamic functions (such as dynamic data presentation). The design template is, for example, an HTML design template. Generally, a web page designer (e.g., art designer) only has web page design related skills (for example, only understands the HTML language), and does not have any non-web page design related skills (such as understanding the java language). During development of dynamic web pages, a developer that has no or only a small amount of web page design related skills is responsible for back-end program encoding and dynamic data generating, but not responsible for controlling presentation style of the web page. A developer can utilize, for example, Perl, Tcl, Java, Python, ASP and many other languages and tools to populate the template in order to realize generation of dynamic data.
There are many popular methods for presenting dynamic data of web pages, for example, Servlet+JSP (JavaServer Page) (or with JSP TagLibs), Velocity, XMLC (eXtensible Markup Language Complier), etc. However, the present methods all require web page designers and developers to cooperatively develop the same template file. For example, first the web page designer finishes the template file (based on a markup language that can be recognized by a standard browser, such as HTML or WML), and then the developer modifies this file and populates program codes that can only be understood by the developer. This inevitably destroys the standard property of the original template file, and possibly causing the modified template to not be recognized by the standard browser. This presents a great challenge for subsequent maintenance by the web page designer, because a lot of program languages that cannot be understood by the web page designer are added into the template, so that the web page designer can no longer perform maintenance with the original web page editor. This will be further described in the following, by taking part of the typical existing techniques as an example.
A Servlet is a kind of Java application running on a web server or application server and is used to provide a server side process, such as accessing a database, etc. The Servlet couples presentation markup content with business logic processes.
The following is a sample snippet of a Servlet.
response.setBufferSize (“8*1024”);response.setContentSize (“text/html”);PrintWriter out = response.getWriter ( );out.printIn (“<HTML>”);out.printIn (“<HEAD> <TITLE> Servlet Output</TITLE> </HEAD>”);out.printIn (“<BODY>”);out.printIn (“<P> Welcome To this World </P>”);out.printIn (“</BODY>”);printIn (“</HTML>”);
Usually, the development flow using the Servlet technique is as follows: the web page designer writes a standard template file (such as an HTML file), then the developer writes servlet code that contains all the templates, with these codes being embedded standard java logic code to display dynamic data. However, the disadvantage of servlet technology is obvious: it is very hard to split presentation markup content and business logic processes. And for further maintenance it is a disaster because any display related data modification (such as changing the font, layout, etc.) requires direct modification of java code, and therefore the whole servlet code needs to be re-compiled and re-deployed.
JSP is an extension to servlet technology, which allows HTML and Java to be incorporated within the same page file, for example, inserting Java into a markup page to produce dynamic content, with Java providing business logic processes, and HTML providing the page that is presented in a web page browser.
A JSP file accesses JavaBean or other components that can send generated dynamic content to a browser. When a web server receives a JSP file request, it sends the request to an application server (such as IBM WebSphere). The application server parses the JSP file and generates a Java source file (which is compiled and run as a Servlet). Unless the original JSP file has been updated, the generation and compilation of the JSP source file do not happen until the first invocation of the Servlet. In this case, the application server will detect the update that was made and re-generate and compile the Servlet before executing it.
The following is a sample snippet of JSP.
<% @ page import = “java.util.Date, java.text.DateFormat” %><HTML><BODY><P> Welcome to JSP development where the time is: <% =DateFormat.getTimeInstance ( ) .format((new Data( ))) %></BODY></HTML>
Although it is not necessary to write presentation markup in programming for JSP, the web page designer and developer must be able to handle/understand the Java program and business logic embedded in the page, which is very difficult for a web page designer because a web page designer can only understand standard HTML and cannot understand any Java program embedded in the HTML. There is great difficulty if it is required at this time for the web page designer to make a post page style modification. A lot of non-HTML standard marked codes are added into the template file at this time, and page edit tools will become unavailable.
Velocity is a Java-based template engine, which permits anyone to use simple and powerful template language to reference objects defined in Java code. Web designers can work in parallel with Java programmers to develop web pages according to Model/View/Controller (MVC) architecture, meaning that web page designers can focus solely on designing web pages, and programmers can focus solely on writing codes.
The following is a sample snippet of Velocity.
<HTML><BODY>Hello $customer.Name!<TABLE>#foreach($mud in $mudsOnSpecial)#if($customer.hasPurchased($mud))<TR><TD>$flogger.getPromo($mud)</TD></TR>#end#end</TABLE></BODY></HTML>
But actually, Velocity template language is very similar to a Java program in JSP. For web page designers, a lot of business logic or other language that cannot be understood are embedded in the template file. Moreover, within a Velocity template, it is required to use its customized VTL (Velocity Template Language). After VTL is added, this template is no longer pure HTML, which also requires that the page developer have certain front-end programming skill. A template which has VTL added into it could not be recognized by a standard HTML editor. Furthermore, Velocity's Merge Engine is centered on a template, i.e., it first reads a template, then compiles the template file and at the same time interprets the VTL embedded in the template, with the VTL accessing Data Context so as to perform dynamic data replacement. Velocity's context is just a data storage center, and there is only data in it without any presentation related information (how to present the data is interpreted by VTL in the template). For example, if there are 10 records to be displayed in a page while there are 20 pieces of data returned by business logic, Velocity's context will put in the 20 pieces of data, then 1-10 will be displayed in cycle by VTL in the template, that is, the display is controlled by the template. All of which have demanded higher requirements for developers.
The XMLC method is to compile a markup language page (such as HTML, XML, or WML) to generate a corresponding Java class. This Java class contains the page's complete DOM (Document Object Model) tree structure and its operation method, so that it can process any content and its attribute on the page. More importantly, in XMLC, dynamic content is cleverly associated with the ID attribute in HTML and corresponding operation methods are generated in the Java class, for example, change attribute of text content, etc. Unlike JSP, XMLC does not introduce any extra HTML/XML tag attribute, but just reuses the ID attribute. Therefore, actually XMLC can process any markup language, not only XML, HTML, and WML.
XMLC processes a markup language page via 3 steps, the work flow of which is as follows.
1. Check whether the input document (HTML, XML, WML, etc.) is valid and whether the tag is legal and complete.
2. Generate a set of Java classes which represents the input document (page) as related DOM tree in development phase. In practice, an instance of such class is created, and the DOM tree of the page can be manipulated by using an instance of this class.
3. A Java method that handles dynamic content is generated. The dynamic content only needs to be marked with ID.
It can be seen that this method has significantly reduced the Java developer's workload on processing a page's dynamic content.
Although XMLC uses standard HTML as the template and uses the ID attribute of HTML as keyword or locating, XMLC requires using its compile tool at the development stage for pre-compiling and compiling the template file into a stack of Java classes. Each Java class encapsulates therein attribute and operation method of the corresponding node in the template, then a programmer introduces these classes in business logic, and assigns values to these nodes through an API (Application programming interface). Finally, the Java program is run to output HTML content. XMLC do not have the concept of Merge Engine and at the same time, the template file is only valid during development, and what is used during runtime is the compiled Java class.
In contrast to Servlet, JSP, and Velocity, XMLC is quite simple for page designers (it is based on a pure HTML template), but more complex for business developers, because when a page (template) changes a little, they have to re-compile the HTML template into a DOM tree, and fix the compile errors (for example <TR>..<TR> should be <TR>..</TR>)
Therefore, there is a need for a technique to generate dynamic web pages based on a template that can be browsed (interpreted) by a browser, so that it is simple for both page designers and developers and makes the relation between them simple, such that either can easily read and understand a modification made by the other.